-
Notifications
You must be signed in to change notification settings - Fork 3.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore: add new interfaces for Assets #12700
Conversation
In V2, we want to get rid of the @aws-cdk/assets module, as it's considered deprecated in V1. Unfortunately, the module contains an interface, CopyOptions, that is used, through interface inheritance, in the public API of many stable CDK modules like ECS, Lambda, ECR, CodeBuild, etc. While we have a CopyOptions interface in @aws-cdk/core, it unfortunately shares the same name, `follow`, with the property in the "old" CopyOptions. But the two different `follow` properties have different types. For that reason, if we're going to remove the "old" CopyOptions using JSII's "strip deprecated" option, we can't use the "new" CopyOptions in the inheritance hierarchy alongside the "old" CopyOptions, as the two definitions of `follow` would conflict. For that reason, create a new FileCopyOptions interface which renames the `follow` property to `followSymlinks`. Also add a FileFingerprintOptions interface that does a similar trick to the FingerprintOptions interface (which extends CopyOptions), which is used in the public API of modules that use Docker assets. Also extract a few module-private interfaces to avoid duplication of properties between all of these interfaces.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cc @eladb who is more familiar with this part of the CDK.
import * as cxapi from '@aws-cdk/cx-api'; | ||
import { Construct } from 'constructs'; | ||
|
||
/** | ||
* Options for DockerImageAsset | ||
*/ | ||
export interface DockerImageAssetOptions extends assets.FingerprintOptions { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I assume changes to this file are not related to your PR description, yes?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't understand what you're asking, sorry. They are very much related (in fact, the description explicitly calls out FingerprintOptions
).
export interface CopyOptions extends FileOptions { | ||
/** | ||
* A strategy for how to handle symlinks. | ||
* | ||
* @default SymlinkFollowMode.NEVER | ||
*/ | ||
readonly follow?: SymlinkFollowMode; | ||
} | ||
|
||
/** | ||
* Options applied when copying directories into the staging location. | ||
*/ | ||
export interface FingerprintOptions extends CopyOptions { | ||
export interface FileCopyOptions extends FileOptions { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need both of these or can we deprecate the former?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Again, sorry, I don't understand what you're asking here (deprecate which interface?).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You don't have to be sorry. It's ok.
I was asking about CopyOptions
and FileCopyOptions
. They look exactly the same.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, we can deprecate CopyOptions
. It's used in a bunch of public classes, so it will require changes to augment CopyOptions
with FileCopyOptions
in all of these usages, and it's not linked to deprecating @aws-cdk/assets
directly.
Let me know if you want to make this part of this PR, or tackle it separately after this is merged.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you get @eladb's eyes on this? He owns and has built this area and it'd best for him to take a look at this PR and assess this change.
I'll defer to him on what the right thing here is.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, but before I approve, can you please add to the PR description the final state that we will have in V2 after the all the deprecations are removed from the library?
@@ -10,6 +10,7 @@ export interface CopyOptions { | |||
* A strategy for how to handle symlinks. | |||
* | |||
* @default Never | |||
* @deprecated use `followSymlinks` instead |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Where is followSymlinks
defined?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's defined in FileCopyOptions
in @aws-cdk/core
.
Co-authored-by: Elad Ben-Israel <benisrae@amazon.com>
@eladb done! Let me know if the description makes sense now. |
Thank you for contributing! Your pull request will be updated from master and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
Thank you for contributing! Your pull request will be updated from master and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
This reverts commit 1a9f2a8.
Needs reverting because of aws/jsii#2256 . This reverts commit 1a9f2a8. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
In V2, we want to get rid of the `@aws-cdk/assets` module, as it's considered deprecated in V1. Unfortunately, the module contains an interface, `CopyOptions`, that is used, through interface inheritance, in the public API of many stable CDK modules like ECS, Lambda, ECR, CodeBuild, etc. While we have a `CopyOptions` interface in `@aws-cdk/core`, it unfortunately shares the same name, `follow`, with the property in the "old" `CopyOptions`. But the two different `follow` properties have different types. For that reason, if we're going to remove the "old" `CopyOptions` using JSII's "strip deprecated" option, we can't use the "new" `CopyOptions` in the inheritance hierarchy alongside the "old" `CopyOptions`, as the two definitions of `follow` would conflict. Because of that, create a new `FileCopyOptions` interface which renames the `follow` property to `followSymlinks`. Also add a `FileFingerprintOptions` interface that does a similar trick to the `FingerprintOptions` interface (which extends `CopyOptions`), which is used in the public API of modules that use Docker assets. Also extract a few module-private interfaces to avoid duplication of properties between all of these interfaces. After this change, an interface from one of the non-deprecated assets libraries (S3 or ECR) using `FileOptions` from `@aws-cdk/assets` will look like this: ```ts // this is in @aws-cdk/aws-s3-assets export interface AssetOptions extends assets.CopyOptions, cdk.FileCopyOptions, cdk.AssetOptions { // ... ``` Then, when we enable stripping the deprecated elements using JSII on the V2 branch, this will be turned to: ```ts export interface AssetOptions extends cdk.FileCopyOptions, cdk.AssetOptions { // ... ``` Allowing us to deprecate the `@aws-cdk/assets` module, and not ship it with `aws-cdk-lib`. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
…s#12832) Needs reverting because of aws/jsii#2256 . This reverts commit 1a9f2a8. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
This is a re-submit of the PR aws#12700, which had to be reverted because of JSII issue aws/jsii#2256. Since that issue has been fixed in JSII version `1.23.0`, which is what we currently use, re-introduce the changes from that PR.
This is a re-submit of the PR #12700, which had to be reverted because of JSII issue aws/jsii#2256. Since that issue has been fixed in JSII version `1.23.0`, which is what we currently use, re-introduce the changes from that PR. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
This is a re-submit of the PR #12700, which had to be reverted because of JSII issue aws/jsii#2256. Since that issue has been fixed in JSII version `1.23.0`, which is what we currently use, re-introduce the changes from that PR. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
This is a re-submit of the PR #12700, which had to be reverted because of JSII issue aws/jsii#2256. Since that issue has been fixed in JSII version `1.23.0`, which is what we currently use, re-introduce the changes from that PR. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
This is a re-submit of the PR aws#12700, which had to be reverted because of JSII issue aws/jsii#2256. Since that issue has been fixed in JSII version `1.23.0`, which is what we currently use, re-introduce the changes from that PR. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
This is a re-submit of the PR #12700, which had to be reverted because of JSII issue aws/jsii#2256. Since that issue has been fixed in JSII version `1.23.0`, which is what we currently use, re-introduce the changes from that PR. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
In V2, we want to get rid of the
@aws-cdk/assets
module, as it's considered deprecated in V1.Unfortunately, the module contains an interface,
CopyOptions
, that is used, through interface inheritance, in the public API of many stable CDK modules like ECS, Lambda, ECR, CodeBuild, etc.While we have a
CopyOptions
interface in@aws-cdk/core
, it unfortunately shares the same name,follow
, with the property in the "old"CopyOptions
. But the two differentfollow
properties have different types.For that reason, if we're going to remove the "old"
CopyOptions
using JSII's "strip deprecated" option, we can't use the "new"CopyOptions
in the inheritance hierarchy alongside the "old"CopyOptions
, as the two definitions offollow
would conflict.Because of that, create a new
FileCopyOptions
interface which renames thefollow
property tofollowSymlinks
. Also add aFileFingerprintOptions
interface that does a similar trick to theFingerprintOptions
interface (which extendsCopyOptions
), which is used in the public API of modules that use Docker assets.Also extract a few module-private interfaces to avoid duplication of properties between all of these interfaces.
After this change, an interface from one of the non-deprecated assets libraries (S3 or ECR) using
FileOptions
from@aws-cdk/assets
will look like this:Then, when we enable stripping the deprecated elements using JSII on the V2 branch, this will be turned to:
Allowing us to deprecate the
@aws-cdk/assets
module, and not ship it withaws-cdk-lib
.By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license